@2403905 This is a much cleaner approach — removing the reva-side cache entirely and keeping it simple in the proxy makes a lot of sense. Happy to help with this PR in any way.

A couple of observations from working on the original #12115:

1. Concurrent request deduplication: The original issue (The Proxy service middleware creating a personal space multiple times #12068) reported 11 simultaneous CreateHome calls on first login. The ttlcache.Has() check will prevent repeated calls after the first one succeeds, but during that initial window (before the first CreateHome returns), concurrent requests will still all fire independently. A singleflight.Group wrapping the CreateHome call would collapse those into a single gRPC call. Happy to add this if you'd like.

2. Tests: I had unit tests from fix(proxy): [OCISDEV-460] deduplicate CreateHome calls in middleware #12115 that could be adapted for this implementation if that would be useful.

Let me know if there's anything I can pick up here.

@paul43210 Thank you for the reply. I think the tests are redundant in this case.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

I don't think we can have a good solution to this. Users can be created outside of oCIS (Keycloak, for example), so we can't create their home when the user is created.
The cause of the multiple requests is because the CreateHome happens in the middleware, without any real control. This means that any request going through the proxy will trigger the request (unless any previous middleware stops the request).

(There is only one GatewayAPI/Authenticate call. It's the same request from the screenshot above it.)

The approach looks fine to me. Just a couple of notes:

• The ttlcache library seems too much for what we need. Not sure if we want to add the library. The ocis-pkg/sync/cache.go should provide something similar. We might need to double-check details.
• I'm not fond of spawning a goroutine that will effectively be running forever. I'm not sure if it will interfere with the normal shutdown procedure because, at the moment, we aren't stopping the goroutine. The ocis-pkg/sync/cache.go doesn't need an additional goroutine, and it keeps the memory usage under control by limiting the capacity of the cache.

I don't think we can have a good solution to this. Users can be created outside of oCIS (Keycloak, for example), so we can't create their home when the user is created. The cause of the multiple requests is because the CreateHome happens in the middleware, without any real control. This means that any request going through the proxy will trigger the request (unless any previous middleware stops the request).

• The ttlcache library seems too much for what we need. Not sure if we want to add the library. The ocis-pkg/sync/cache.go should provide something similar. We might need to double-check details.
• I'm not fond of spawning a goroutine that will effectively be running forever. I'm not sure if it will interfere with the normal shutdown procedure because, at the moment, we aren't stopping the goroutine. The ocis-pkg/sync/cache.go doesn't need an additional goroutine, and it keeps the memory usage under control by limiting the capacity of the cache.

I agree it is not the best solution. The goal I reached in this pull request is to push the part of the changes from the #12108

I chose the github.com/jellydator/ttlcache/v3 because this package is already used in a proxy.